If you do not care about the deployment details for now and just want to get started take a look at the ERRAI:Quickstart Guide.
The CDI integration is a plugin to the Errai core framework and represents a CDI portable extension. Which means it is discovered automatically by both Errai and the CDI container. In order to use it, you first need to understand the different runtime models involved when working GWT, Errai and CDI.
Typically a GWT application lifecycle begins in Development Mode and finally a web application containing the GWT client code will be deployed to a target container (Servlet Engine, Application Server). This is no way different when working with CDI components to back your application.
What's different however is availability of the CDI container across the different runtimes. In GWT development mode and in a pure servlet environment you need to provide and bootstrap the CDI environment on your own. While any Java EE 6 Application Server already provides a preconfigured CDI container. To accomodate these differences, we need to do a little trickery when executing the GWT Development Mode and packaging our application for deployment.
In development mode we need to bootstrap the CDI environment on our own and make both Errai and CDI available through JNDI (common denominator across all runtimes). Since GWT uses Jetty, that only supports read only JNDI, we need to replace the default Jetty launcher with a custom one that will setup the JNDI bindings:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven plugin</artifactId>
<version>${gwt.maven}</version>
<configuration>
...
<server>org.jboss.errai.cdi.server.gwt.JettyLauncher</server>
</configuration>
<executions>
...
</executions>
</plugin>
Consequently, when starting Development Mode from within your IDE the following program argument has to be provided: -server org.jboss.errai.cdi.server.gwt.JettyLauncher
JettyLauncher uses different class loaders to load classes that belongs to the web application, the Jetty server, and the Java standard library itself. In the majority of cases, you can simply put all dependencies into your web application's WEB-INF/lib folder. However, there are cases where putting a dependency in WEB-INF/lib will cause troubles such as ClassCastException when same class is also loaded by a different classloader. To mitigate this problem, JettyLauncher can be instructed that certain classes (or packages) shall be loaded only by the system class loader. To do so, set the Java system property jetty.custom.sys.classes when launching Dev Mode.
For example, when using gwt-maven-plugin:
<extraJvmArgs>-Djetty.custom.sys.classes=bitronix;javax.transaction</extraJvmArgs>
Once this is set up correctly, we can bootstrap the CDI container through a servlet listener:
<web-app>
...
<listener>
<listener-class>org.jboss.errai.container.CDIServletStateListener</listener-class>
</listener>
<resource-env-ref>
<description>Object factory for the CDI Bean Manager</description>
<resource-env-ref-name>BeanManager</resource-env-ref-name>
<resource-env-ref-type>javax.enterprise.inject.spi.BeanManager</resource-env-ref-type>
</resource-env-ref>
...
</web-app>
Deployment to servlet engine has basically the same requirements as running in development mode. You need to include the servlet listener that bootstraps the CDI container and make sure both Errai and CDI are accessible through JNDI. For Jetty you can re-use the artefacts we ship with the archetype. In case you want to run on tomcat, please consult the Apache Tomcat Documentation.
We provide integration with the JBoss Application Server, but the requirements are basically the same for other vendors. When running a GWT client app that leverages CDI beans on a Java EE 6 application server, CDI is already part of the container and accessible through JNDI (java:/BeanManager).